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(54) System and method tor operating a communication network on an ATM platform 



(57) A system and method of operating a communi- 
cations network having a plurality of interconnected 
nodes is provided by: establishing a connection path 
from an ingress node to an egress node through inter- 
mediate nodes; associating the connection path with a 
network-wide unique identification; on the ingress node, 
storing the path identification so as to indicate that the 



path originates at the ingress node; on each intermedi- 
ate node, storing the path identification so as to indicate 
that the path transits the intermediate node; and on the 
egress node, storing the path identification so as to in- 
dicate that the path terminates at the ingress node. 
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Description 
FIELD OF ART 

[0001] The invention relates to the art of digital com- 
munication systems and more specifically to an imple- 
mentation of a network employing multi-protocol label 
switching (MPLS) over an asynchronous transfer mode 
(ATM) platform. 

BACKGROUND OF INVENTION 

[0002] MPLS is quickly gaining support in the industry 
as a robust way of transmitting Internet Protocol (IP) 
packets. This is primarily because MPLS eliminates the 
need to examine the destination IP address of a packet 
at every router or network node in the path of the packet 
As such, MPLS has particular utility in the high speed 
core of many networks. Recognizing that within the high 
spee d core ATM switching infrastructure is likely to ex- 
ist, the industry is presently in the process of f ormulating 
standards for deploying MPLS over an ATM infrastruc- 
ture. 

[0003] As in the nature of most standardization ef- 
forts, the focus has been to define the functional fea- 
tures necessary to enable interoperability amongst 
equipment manufactured by a variety of participants. 
However, many problems arise in implementing MPLS 
functionality. These include: (1) the general manage- 
ment and maintenance of signalled label switched paths 
(SLSP) on an ATM infrastructure; (2) procedures on the 
failed establishment of an SLSP; (3) management of 
signalling links; (4) procedures when a signalling link or 
physical link fails; and (5) procedures under various 
changes in network topology, such as the creation of a 
new signalling link. The present invention seeks to pro- 
vide solutions to these various issues. 

SUMMARY OF INVENTION 

[0004] One aspect of the invention relates to a method 
of transmitting packets received from a connectionless 
network, such as an IP network wherein each packet 
includes a destination network address, over a connec- 
tion-orientated network, such as an ATM network. Ac- 
cording to the method a forwarding table is provided 
wherein each network address is associated with a sin- 
gle interface index which dictates an output port and a 
connection over which corresponding packets should 
transported. Connectionless packets are forwarded to 
an output port based on an interface index obtained from 
the forwarding table. The connectionless packets are 
thus transmitted over the corresponding connection. A 
routing table is maintained in order to route connection- 
less, packets over a connection-oriented network. The 
routing table associates each network address with one 
or more interface indexes. Each interface index is also 
associated with an application, one application being 



connectionless routing and one application being label 
switching. Interface indexes are downloaded from the 
routing table to corresponding entries in the forwarding 
table such that the labei switching application has a 
5 higher priority than the connectionless routing applica- 
tion. 

[0005] In a second aspect, a method of operating a 
communications network having interconnected nodes 
is provided. The method comprises establishing a con- 
to nection path from an ingress node to an egress node 
through intermediate nodes, associating the connection 
path with a network-wide unique identification, on the 
ingress node, storing the path identification so as to in- 
dicate that the path originates at the ingress node, on 
is each the intermediate node, storing the path identifica- 
tion so as to indicate that the path transits the interme- 
diate node and on the egress node, storing the path 
identification so as to indicate that the path terminates 
at the ingress node. 
20 [0006] The method may have the step of establishing 
a connection path including signalling a connection set- 
up request from the ingress node through the interme- 
diate nodes to the egress node. Further, the step of es- 
tablishing a connection path may include signalling an 
25 acknowledgement from the egress node through the in- 
termediate nodes to the ingress node in response to the 
connection set-up request 

[0007] In a third aspect, the invention provides a 
method of transmitting packets received from a connec- 

30 tionless network. Each packet includes a destination 
network address. The method provides a forwarding ta- 
ble wherein each network address is associated with a 
single interface index which dictates an output port and 
a connection over which corresponding packets should 

35 transported, forwards a connectionless packet to an out- 
put port based on an interface index obtained from the 
forwarding table and transmits the connectionless pack- 
et over the corresponding connection, maintains a rout- 
ing table for routing connectionless packets over a con- 

40 nection-oriented network, the routing table associating 
each network address with one or more interface index- 
es, associates each interface index with an application, 
one application being connectionless routing and one 
application being label switching and downloads inter- 

45 face indexes from the routing table to corresponding en- 
tries in the forwarding table such that the label switching 
application has a higher priority than the connectionless 
routing application. 

[0008] In a fourth aspect, the invention provides a 
so method of transmitting packets. The method includes 
receiving (a) connection-oriented packets having a label 
associated therewith, the label being a connection iden- 
tifier, and (b) connectionless packets carrying a network 
address and having no label associated therewith, pro- 
55 viding a forwarding table wherein each network address 
is associated with a single interface index which dictates 
an output port and a connection over which correspond- 
ing connectionless packets should transported, provid- 
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ing a switching table for switching ingress labels into 
egress labels, forwarding a connectionless packet to an 
output port based on an interface index obtained from 
the forwarding table, forwarding a connection-oriented 
packet to an output port based on the switching table, s 
transmitting connection-oriented and connectionless 
packets over the corresponding connections, maintain- 
ing a routing table for routing connectionless packets 
over a connection-oriented network, the routing table 
associating each network address with one or more in- 10 
terface indexes, associating each interface index with 
an application, one application being connectionless 
routing and one application being label switching and 
downloading interface indexes from the routing table to 
corresponding entries in the forwarding table such that *5 
the label switching application has a higher priority than 
the connectionless routing application. 
[0009] In a fifth aspect, the invention provides a net- 
work node. The node comprises input and output ports 
operative to receive and transmit packets carrying a 20 
connection identifier for transport over a connection-ori- 
ented network, switching logic for switching the connec- 
tion-oriented packets from one of the input ports to one 
of the output ports based on one of the connection iden- 
tifiers, segmentation and re-assembly logic for enabling 25 
the ports to assemble connectionless packets from the 
pay loads of one or more connection-oriented packets 
on ingress and to segment each such connectionless 
packet into one or more connection-oriented packets on 
egress, each the message packet carrying a network 30 
address for transport over a connectionless network, 
forwarding logic for forwarding connectionless packets 
from one of the input ports to one of the output ports, 
the forwarding logic including a forwarding table which 
associates a network address or a group of network ad- 35 
dresses with a single interface index, the interface index 
indicating the identity of one of the output ports and en- 
abling a connection identifier to be specified for segmen- 
tation of the connectionless packet at the indicated out- 
put port, routing logic for forwarding a connectionless 40 
packet to a next-hop based on the network address car- 
ried by the packet, the logic including a routing table 
which associates a network address or group thereof 
with at least one interface index, the logic being enabled 
to download an Interface index for a given network ad- 45 
dress or group thereof from the routing table to the same 
network address entry in the forwarding table time and 
logic for setting up a label switched path wherein a con- 
nectionless packet is associated with a connection iden- 
tifier which functions as a label so that transit nodes in so 
the label switched path can switch the conhection : ori- 
entatedpackets constituting connectionless packets 
based on the connection identifier without re-assem- 
bling the connectionless packets, the logic associating 
the label switched path with an interface index. The in- 55 
terface indexes are associated with a priority hierarchy 
in which interface indexes associated with label 
switched paths have a higher priority than interface in- 
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dexes associated with connectionless routing and the 
routing logic does not overwrite a forwarding table entry 
having an interface index associated with a label 
switched path with an interface index associated with 
connectionless routing. 

[0010] In other aspects, the invention provides vari- 
ous combinations and subsets of the aspects described 
above. 

BRIEF DESCRIPTION OF DRAWINGS 

[0011] The foregoing and other aspects of the inven- 
tion will become more apparent from the following de- 
scription of specific embodiments thereof and the ac- 
companying drawings which illustrate, by way of exam- 
ple only, the principles of the invention. In the drawings, 
where like elements feature like reference numerals 
which may bear unique alphabetical suffixes In order to 
identify specific instantiations of like elements): 

Fig. 1 is a system block diagram of a network node 
which processes ATM cells and IP packets; 
Fig. 2 is process flow diagram showing how IP pack- 
ets are processed in the node of Fig. 1 ; 
Rg. 3 is a diagram of a forwarding table employed 
by IP forwarders associated with input /output con- 
trollers of the node of Figure 1 ; 
Fig. 4 is a diagram of a data structure representing 
a "service interface" associated with nodes such as 
shown in Fig. 1; 

Fig. 5 is an architectural block diagram of hardware 
processors and software processes associated 
with a control card on the node of Fig. 1 ; 
Fig. 6 is a master IP routing table associated with 
an IP network; 

Fig. 7 is a diagram of a reference network illustrating 
an MPLS domain within an IP network; 
Fig. 8 is a schematic diagram of a database em- 
ployed by the node of Rg. 1 to manage signalled 
label switched paths (SLSPs); 
Figs. 8A and 8B show certain f ields of the database 
of Fig. 8 in greater detail; 

Figs. 9 and 10 are logic flow charts showing the 
steps executed by the node of Fig. 1 in establishing 
anSLSP;and 

Fig. 11 Is a logic flow chart showing the steps exe- 
cuted by the node in the event a new SLSP signal- 
ling link is established. 

DETAILED DESCRIPTION OF ILLUSTRATIVE 
EMBODIMENT 

[0012] The description which follows, and the embod- 
iments therein, are provided by way of illustrating an ex- 
ample, or examples, of particular embodiments of prin- 
ciples of the present invention. These examples are pro- 
vided for the purpose of explanation, and not limitations, 
of those principles. In the description which follows, like 
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elements are marked throughout the specification and 
the drawings with the same respective reference numer- 
als. 

1 . Overview of ATM Switching 

[0013] Fig. 1 is an architectural block diagram of an 
exemplary dual function ATM switch and IP router 10 
(hereinafter "node"). The node 10 comprises a plurality 
of input/output controllers such as line cards 12 which 
have physical interface input/output ports 14. Generally 
speaking, the line cards 12 receive incoming ATM cells 
on ports 14. Each ATM cell, in accordance with stand- 
ardized ATM communication protocols, is of a fixed size 
and incorporates a virtual path identifier (VPI) and a vir- 
tual channel identifier (VCI) so that the cell can be as- 
sociated with a particular virtual circuit (VC). For each 
such cell received, the line cards 12 consult a lookup 
table or content addressable memory (CAM) 15 keyed 
on VCs. The CAM 1 5 provides pre-configured address- 
ing information as to the outgoing port and egress line 
card for each cell. This is accomplished by way of an 
"egress connection index", which is a pointer to a pre- 
configured memory location on the egress line card that 
stores a new VC identifier that should be attributed to 
the cell as it progresses its way over the next network 
link. The ingress line card attaches the addressing in- 
formation and egress connection index to each cell and 
sends it to a switching fabric 20 which physically redi- 
rects or copies the cell to the appropriate egress line 
card. The egress line card subsequently performs the 
pre-configured VPl/VCI field replacement and transmits 
the cell out of the egress port. Further details of this type 
of ATM switching mechanics can be found in PCT pub- 
lication no. WO95/30318, all of which is incorporated 
herein by reference. 

[001 4] The node 1 0 also features a control card 24 for 
controlling and configuring various node functions, in- 
cluding routing and signalling functions, as described in 
much greater detail below. The line cards 1 2 may send 
data received at ports 14 to the control card 24 via the 
switching fabric 20. 

[0015] Each line card supports bidirectional traffic 
flows (i.e., can process incoming and outgoing packets). 
However for the purposes of description the following 
discussion assumes that line card 12A and ports 14A1 
and 14A2 provide ingress processing and line cards 
12B, 12C and ports 14B1, 14B2, 14C1, 14C2 provide 
egress processing for data traffic flowing from left to right 
in Fig. 1. 

2. Overview of IP Routing 

[0016] The node of the illustrated embodiment also 
enables variable length packets of digital data associat- 
ed with a hierarchically higher communications layer, 
such as Internet Protocol (IP), to be carried over the 
ATM transport layer infrastructure. This is made possi- 



ble by segmenting each variable length packet into a 
plurality of ATM cells for transport. Certain VCs may thus 
be dedicated to carrying IP packets, while other VCs 
may be exclusively associated with native ATM commu- 
5 nications. 

[0017] When a cell arrives at ingress port 14A1 the 
line card 12A accesses CAM 15A to obtain context in- 
formation for the VC of the arriving cell, as previously 
described. The context information may associate the 

w VC with a "service interface". This is an endpoint to a 
link layer (i.e. "layer 2") path, such as an AAL5 ATM 
path, through a network. A number of service interfaces 
(Sis) may exist on each I/O port 14. These service in- 
terfaces "terminate" at an IP forwarder 22 on the same 

15 line card in the sense that, as subsequently described, 
the ATM cells constituting an IP packet are reassembled 
into the packet, following which IP forwarding proce- 
dures (as opposed to ATM switching procedures) are 
followed 

20 [0018] The essence of IP forwarding is that an IP 
packet received at one SI is retransmitted at another SI. 
Referring additionally to the process flow chart shown 
in Fig. 2, the forwarding process for IP packets can be 
logically divided into three transport stages, separated 

25 by two processing stages, through the node. 

[0019] The first transport stage, schematically repre- 
sented by arrows 1 6A, carries ATM cells associated with 
an ingress SI from the ingress port 14A1 to the ingress 
IP forwarder 22A. 

30 [0020] The second transport stage carries I P packets 
from the ingress IP forwarder 22A across the switching 
fabric 20 to an egress IP forwarder, e.g., forwarder 22B. 
This second transport stage is implemented via a "con- 
nection mesh" 21 . Within the connection mesh eight in- 

35 temal connections or transport interfaces (TIs) 18 are 
set up between each pair of IP forwarders 22 (only three 
TIs are shown). The TIs are provided so as to enable 
different levels or classes of service (COS) for IP pack- 
ets. 

40 [0021 ] The third transport stage, schematically repre- 
sented by arrows 16B, carries IP packets from the 
egress IP forwarder 22B to the egress port, e.g. port 
14B1, and egress SI. 

[0022] The first processing stage occurs at the in- 
45 gress IP forwarder 22A, where the ATM cells associated 
with an ingress SI are reassembled into IP packets. This 
is shown as step "A" in Fig. 2. At step °B" the IP forward- 
er 22A then examines the destination IP address of the 
packet in order to determine the appropriate egress SI 
so for the "next hop" through the network. This decision is 
based on an IP forwarding table 30 (derived frorn IP pro- 
tocols, as discussed in greater detail below) shown 
schematically in Fig. 3. Each record of table 30 includes 
an IP address field 32 and an "egress interface index" 
55 field 36. The IP destination address of the packet is 
looked up in the IP address field 32 to find the longest 
match thereto (i.e., the table entry which resolves the 
packet IP address destination as far as possible). The 
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corresponding egress interface index essentially spec- 
ifies the egress line card 1 2B, egress IP forwarder 22B. 
and the egress SI for the packet (see more particularly 
the discussion with reference to Fig. 8A). The egress 
interface index is attached to the IP packet. 
[0023] In addition, at step 'C 0 the IP forwarder 22A 
examines the class of service (COS) encapsulated by 
the packet. Based partly on the encapsulated COS and 
internal configuration, the IP forwarder 22A selects one 
of the second-stage TIs 1 8 which will reach the egress 
forwarder 22B with a desired class of service. In order 
to traverse the switching fabric 20, the ingress IP for- 
warder 22 A re-segments the IP packet into ATM ceils 
(shown schematically as step D D°) and attaches ad- 
dressing information to each cell indicating that its des- 
tination is the egress IP forwarder 22B. 
[0024] The second, smaller, processin g stage occurs 
at the egress IP forwarder 22B, where the egress Inter- 
face index is extracted from the packet and it is modified 
at step "E" to match the encapsulation associated with 
the egress SI. Thus, the VPI/VCI associated with the 
egress SI is attached to the packet. The packet is then 
delivered to that egress SI (labelled "G") using the third- 
stage transport 1 6B corresponding thereto. In this proc- 
ess the packet is segmented once again into ATM cells 
which are buffered in cell queues associated with the 
egress SI and/or output port 14B1 . A queuing and pos- 
sible congestion point (labelled "F°) also occurs be- 
tween the second processing and third transport stage 
- that is, between the egress IP forwarding module 22B 
and the egress S! (labelled "G"). 
[0025] It will be seen from the foregoing that effecting 
IP forwarding functionality on an ATM platform is a rel- 
atively involved process, requiring that the IP packet be: 
(a) reassembled at the ingress IP forwarder 22A, (b) 
subsequently segmented for transport over the switch- 
in g fabric, (c) re-assembled at the egress forwarder 22B, 
and (d) subsequently re-segmented for transmission out 
of the output port. In addition, a non-trivial IP address 
lookup has to be performed at the ingress forwarder 
22A. These steps have to be performed at each network 
node and hence increase the latency of end-to-end 
communication. 

3. Introduction to MPLS 

[0026] In order to avoid having to perform the above 
procedures on each and every packet, the node 1 0 pro- 
vides multi-protocol label switching (MPLS) capability. 
In conventional IP forwarding, routers typically consider 
two packets to be in the same "forward equivalency 
class 0 (FEC) if there is some address prefix in that rout- 
er's tables which is the longest match for the destination 
address of each packet Each router independently re- 
examines the packet and assigns it to a FEC. In con- 
trast, in MPLS a packet is assigned to a FEC only once 
as the packet enters an MPLS domain, and a "label 0 rep- 
resenting the FEC is attached to the packet When 



MPLS is deployed over an ATM infrastructure, the label 
is a particular VC identifier. At subsequent hops within 
an MPLS domain the IP packet is no longer examined. 
Instead, the label provides an index into a table which 

5 specifies the next hop, and a new label. Thus, at sub- 
sequent hops within the MPLS domain the constituent 
ATM cells of a packet can be switched using conven- 
tional ATM switching techniques. Such paths are known 
in the art as label switched paths (LSPs), and LSPs may 

10 be manually set up as permanent label switched paths 
(PLSP) by network operators. Alternatively, a label dis- 
tribution protocol (LDP) may be employed wherein the 
network automatically sets up the path upon command 
from the network operator. Such paths are typically re- 

15 ferred to in the art as soft^permanent or signalled LSPs 
(SLSPs). Further details concerning MPLS can be found 
in the following draft (I.e. work in progress) MPLS stand- 
ards or proposals, each of which Is incorporated herein 
by reference: 

20 

[1] E. Rosen, A. Viswanathan, R. Callon, Multiproto- 
col Label Switching Architecture, draft ietf-mpls- 
arch-06.txt. 

[2] L. Andersson, P. Doolan, N. Feldman, A. Fredette, 
25 B.Thomas, LDP Specification, draft ietf-mpls-ldp- 

06.txt. This LDP is hereinafter referred to as "LDP 
Protocol*. 

[3] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter,. 
E. Rosen, G. Swallow, P. Doolan, MPLS Using 
30 LDP and ATM VC Switching, draft-ietf-mpls-atm- 

02.txt. 

[4] B. Jamoussi, Constraint -Based LSP Setup using 
LDP, draft iet-mpls-cr-ldp-01 .txt. This LDP is here- 
inafter referred to as "CRLDP". 
35 [5] E. Braden et al., Resource Reservation Protocol, 
RFC 2205. This LDP is hereinafter referred to as 
"RSVP". 

[0027] The node 10 implements MPLS functionality 

40 through an SI linkage, as will be better understood by 
reference to Fig. 4 which shows the SI in the context of 
a management entity or record. The SI has an internal 
ID number associated therewith. In addition to repre- 
senting an ATM link layer endpoint, the SI also repre- 

45 sents an IP address for layer 3 functionality, and indi- 
cates what type of encapsulation is used for IP purpos- 
es. Each SI may also be associated with a number of 
other attributes and methods. In particular, Sis can be 
associated with the following methods or applications: 

so (1) |p forwarding, (2) MPLS forwarding, (3) IP routing, 
and (4) MPLS signalling. In other words, the node/10 
can be configured to (1) forward IP data packets to the 
next hop router via the above described IP forwarding 
procedures discussed above; (2) forward IP data pack- 

55 ets via MPLS forwarding procedures as will be dis- 
cussed below; (3) process packets carrying messages 
for IP routing protocols; and (4) process packets carry- 
ing messages for MPLS signalling protocols. 
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4. Overview of MPLS Architecture 

[0028] Rg. 5 shows the hardware and software archi- 
tecture of the control card 24 in greater detail. From the 
hardware perspective, the card 24 employs a distributed 5 
computing architecture involving a plurality of discrete 
physical processors (which are represented by rectan- 
gular boxes in the diagram). 

[0029] Processor 50 handles layer 2 ( D L2") ATM ad- 
aptation layer packet segmentation and reassembly 10 
functions for signalling messages. As mentioned, cer- 
tain Sis will be associated with various types of routing 
protocols and upon receipt of a packet associated with 
one of these Sis the ingress IP forwarder 22A sends the 
packet (which is re-segmented to traverse the switching 
fabric 20) to the 12 processor 50. After re-assembly, the 
L2 processor 50 sends signalling messages associated 
with IP routing protocols to a software task termed "IP 
Routing" 68 which executes on a routing processor 58. 
(The connection between the L2 processor 50 and IP 
Routing 68 is not shown). Signalling messages associ- 
ated with MPLS LDP protocols are sent to a label man- 
agement system task (LMS) 64 executing on a layer 3 
(L3) processor 54. Outgoing messages from the LMS 
64 and IP Routing 68 are sent to the L2 processor 50 
for subsequent delivery to the appropriate egress line 
card and egress SI. 

[0030] IP Routing 68 runs an IP interior gateway or 
routing protocol such as l-BGP, ISIS, PIM, RIP orOSPF. 
(The reader is referred to http y/www. ietf.org ./html. char- 
ters/wg-dir.html for further information concerning these 
protocols.) As a result of these activities IP Routing 68 
maintains a master IP routing table 75 schematically 
shown in Fig. 6. Each record of the master table 75 in- 
cludes a field 75a for an I P address field, a field 75b for 
the next hop router ID (which is an IP address in itself) 
corresponding to the destination IP address or a prefix 
thereof, and a list 75c of egress interface indexes asso- 
ciated with the next hop router ID. As the network topol- 
ogy changes, IP Routing will update the forwarding ta- 
bles 30 of IP forwarders 22 by sending the appropriate 
egress interface index to it. (Note that table 30 only has 
one egress interface index associated with each IP des- 
tination address entry.) 

[0031] As shown in Fig. 5, the node 1 0 employs a plu- 
rality of L3 processors 54, each of which includes an 
LMS 64. Each LMS 64 terminates the TCP and UDP 
sessions for the LDP signaling links (LDP Session) and 
runs a state machine for each LSP. As discussed in 
greater detail below, the LMS 64 receives requests to 
set up and tear down LDP Sessions, and to set up and 
tear down SLSPs. 

[0032] The LMS 64 is commercially available from 
Harris & Jeffries of Dedham, MA. For intercompatibility 
purposes, the node 10 includes "translation" software, 
the MPLS context application manager (MPLS CAM) 
65, which translates and forwards incoming or outgoing 
requests/responses between the LMS and the remain- 



ing software entfries of the control card 24. 
[0033] Each L3 processor 54 also includes a call- 
processing task 72. This task maintains state informa- 
tion about connections which have been requested. 
[0034] Another processor 56 provides user interface 
functionality, including interpreting and replying to ad- 
ministrative requests presented through a central net- 
work management system (NMS) (such as the New- 
bridge Networks Corporation 46020™ product) or 
through command instructions provided directly to the 
node via a network terminal interface (NTI). For MPLS 
functionality, a user interface 66 is provided for accept- 
ing and replying to management requests to program 
PLSPs, SLSPs, and LDP Sessions. 
[0035] A resource control processor 52 is provided for 
allocating and de-allocating resources as connections 
are established in the node. For MPLS functionality, 
processor 52 Includes a label manager task 62 which 
allocates unique label values for LSPs. 
[0036] On the routing processor 58, a software task 
termed °MPLS Routing" 70 interfaces between the Ul 
66, IP Routing 68 and the LMSs 64 running on the L3 
processors 54. Broadly speaking, MPLS Routing 70 
manages SLSPs. For example, during path setup, 
MPLS Routing 70 receives an SLSP setup request from 
the user interface 66, retrieves next hop routing infor- 
mation from IP Routing 68, chooses an LDP Session to 
the next hop, and calls the appropriate instantiation of 
the LMS 64 to set up the SLSP path using the selected 
LDP Session. When a label mapping is received for the 
path, the LMS 64 informs MPLS Routing 70. MPLS 
Routing 70 then triggers an update to the forwarding ta- 
bles 30 of the IP forwarders 22 for the new path. Simi- 
larly, when the network topology changes, MPLS Rout- 
ing 70 reflects these changes into the MPLS routing do- 
main. The functions of MPLS Routing are the focus of 
the remainder of this description. 

5. Reference Network 

[0037] Rg. 7 shows a reference IP network 80 where- 
in an MPLS routing domain exists amongst routers/ 
nodes A, B and C, the remaining of the network 80 em- 
ploying IP specific routing protocols such as OSPF. As- 
sume the network operator wishes to establish an SLSP, 
commencing from node A.for IP destination address 
1.2.3.4 (hereinafter "FEC Z") located somewhere in the 
network. (Note that a FEC, as per the draft MPLS stand- 
ards, comprises a destination IP address and a prefix 
thereof.) The network operator may enter a manage- 
ment command at node A via its NMTi or the NMS (not 
shown) requesting the establishment of a SLSP for FEC 
Z. Depending on the type of label distribution protocol 
employed (e.g., LDP Protocol, CRLDP, or RSVP) the 
network operator may specify the destination node for 
the SLSP, or even explicitly specify the desired route for 
the SLSP up to some destination node (i.e., a source- 
routed SLSP). In the further alternative, the label distri- 
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bution protocol may use a best effort policy (e.g., in LDP 
Protocol) to identify nodes (within the MPLS routing do- 
main) as dose as possible to the destination address of 
FEC Z. In the illustrated reference network, assume that 
node C is the "closest* node within the MPLS routing 5 
domain for FEC Z. 

[0038] In the network 80 t signalling links 82 (which are 
associated with particular SFs) are provided for commu- 
nicating IP routing messages between the nodes. In ad- 
dition, signalling finks 84 are provided for communicat- m> 
ing MPLS label distribution protocol messages therebe- 
tween. Each signalling link 84 has an LDP Session as- 
sociated therewith. 

[0039] For the purposes of nomenclature, unless the 
context dictates otherwise, the term "ingress SLSP" is *5 
used to identify the SLSP at the originating node (e.g., 
node A), the term "transit SLSP" is used to identify the 
SLSP at transiting nodes (e.g., node B), and the term 
"egress SLSP" is used to identify the SLSP at the des- 
tination node (e.g., node C). 20 
[0040] The reference IP network shown in Fig. 7 is 
used to provide the reader with a typical application 
which will help to place the invention in context and aid 
in explaining it. Accordingly, the invention is not limited 
by the particular application described herein. 25 

6. Database Management of SLSPs 

[0041] In order to create, monitor and keep track of 
ingress, transit and egress SLSPs, MPLS Routing 70 30 
maintains a number of tables or data repositories as 
shown in the database schema diagram of Fig. 8. Since 
each SLSP is managed by an LDP Session, MPLS 
Routing 70 on each node keeps track of the various LDP 
Sessions which have been set up between the node and 
its LDP peer routing entities using an LDP signalling da- 
tabase (LSLT) 1 00. The LSLT 1 00 comprises a hash ta- 
ble 102 having one entry or record 104 per LDP routing 
peer. Record 104 contains a router id field 104a which 
functions as the index for the hash table 1 02 and a point- 
er 104b (i.e., *ldp_session_list) which points to an LDP 
session list 1 06. The router id field 1 04a stores the IP 
address of the LDP peer router to which one or more 
LDP Sessions have been configured. Each LDP Ses- 
sion is represented by an entry or record 108 in the 
polnted-to LDP session list 1 06. Note that multiple LDP 
Sessions can be configured between the node and a 
given MPLS peer router and hence the session list 1 06 
can have multiple entries or records 108. In Fig. 8, two 
LDP Sessions have been configured with respect to the 
LDP peer router identified by the illustrated router id field 
104a, and hence two records 108 exist in the corre- 
sponding LDP session list 1 06. 

[0042] Each record 108 of the LDP session list 106 
comprises the following fields: . 

• iflndex (108a) - A unique number within the node 
10 which identifies a particular interface index and 



SI which has been configured for the LDP applica- 
tion. Fig. 8A shows the structure of the iflndex field 
in greater detail. It comprises a node-internal device 
address for the line card/IP module responsible for 
the SI, the egress port, the SI ID number (which is 
only unique per line card) and an identif ication code 
or internal device address for the L3 processor 54 
on the control card 24 handling the LDP signalling 
link. 

• *fitjist_entry (108b) - A pointer to a FEC informa- 
tion table (FIT) 1 1 0. The FIT, as described in greater 
detail below, keeps track of all ingress SLSPs stem- 
ming from the node. The fit Jist_entry pointer 1 08b 
points to a list within FIT 110 of the ingress SLSPs 
associated with this LDP Session. 

• ldp_status (1 08c) - A status indication The status 
includes a one bit flag (not shown) indicating wheth- 
er or not the LDP Session Is in use and a one bit 
flag (not shown) indicating whether resources are 
available for the LDP Session. An LDP Session is 
considered to have no resources available when 
there are no labels available for allocation or when 
the associated SI becomes non-operational. 

• *next_Up_session - A pointer to another LDP Ses- 
sion record 108 associated with the same LDP peer 
router. 

[0043] The FIT 110 keeps track of ingress SLSPs, i. 
e., SLPs which have commenced from the node. (Note 
that the FIT 1 1 0 does not keep track of transit or egress 
SLSPs) A FIT entry or record 112 is created by MPLS 
Routing 70 when an SLSP is configured and record 112 
is removed from the FIT 100 when an SLSP is deleted. 
[0044] Each FIT entry or record 1 1 2 comprises the fol- 
lowing elements: 

• "prev_f itEntry (1 1 2a) - A pointer to a pointer which 
references the current entry. This is used for ease 
of addition and removal from a list. 

• FEC - IP destination for an LSP. The FEC consists 
of an IP destination address 1 1 2b and a prefix 1 1 2c 
for which the LSP is destined, as perthe draft stand- 
ards. 

• Srtjndex (1 1 2d)- An index into a source-route table 
or list (SRT) 114. This takes on the value 0 if the 
LSP is not source-routed and >0 if it is. In the event 
the SLSP establishment command includes a 
source routed path, the router ID IP addresses are 
stored in the SRT 114 in sequential order, as shown. 

• iflndex (112e) - Specifies the egress line card and 
egress SI used to reach the next hop router for the 
FEC. The structure of this field is the same as 
shown in Fig. 8A. Note, however, that in the FIT 110 
this field 112e specifies the SI for the egress data 
path (as opposed to signaling channel) for the FEC. 

• fecStatus (1 1 2f) - The state of this FIT entry as rep- 
resented (see Fig. 8B) by attl value, an ingressSet- 
up flag, a retrySeq counter, and a rertySec counter. 
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The ttl value indicates a time to live value that 
should be decremented from the incoming packets. 
The ingresSetup flag indicates that the SLSP is suc- 
cessfully established. The retrySeq counter keeps 
track of the number of times MPLS Routing has tried 5 
to set up this SLSP, as described in greater detail 
below. The retrySec counter keeps track of how 
many seconds are left until the next retry is attempt- 
ed. 

• lsp_id (112g) - A unique identifier used to identify 10 
an SLSP within an MPLS domain, in the present 
embodiment the identifier comprises a concatena- 
tion of the node's IP router ID plus a unique number 
selected by the Ul 66 to uniquely identify the LSP 
within the node. The lsp_id is also used as a hash « 
key for the FfT 110. 

• # RWTptr (112h) - A pointer to a route watch data- 
base (RWT) 120 described in greater detail below. 

• Next.RTLPtr (1121),* prev.RTLPtr(112j) - Forward 
and backward pointers used to keep track of FIT so 
entries 112 in which the ingressSetup flag of the fee- 
Status field 112f indicates that the corresponding 
SLSP has not been successfully set up. These 
pointers are basically used to implement a retry list 
(RTL) 116 which is embedded in the FIT 110. For 25 
example, the FIT entries 112 labelled "A" and n B B 
form part of the RTL 1 1 6. The RTL thus enables the 
node to quickly traverse the FIT 1 1 0 to find pending 
SLSPs for all peer routers. 

• *next_fitEntry (112k) -Apointerto the next FEC/FIT 30 
entry which has been set up using the same LDP 
Session as the current FEC/ FIT entry. 

[0045] The RWT 120 keeps track of all SLSPs han- 
dled by the node, i.e., ingress, transit and egress 35 
SLSPs. The RWT 1 20 comprises a hash table 1 22 which 
includes an IP designation address field 1 22a, an IP pre- 
fix field 122b, and a *rwt-eritry 122C which points to a 
list 124 of LSPs described in greater detail below. 
[0046] The IP destination address and prefix fields *o 
1 22a and 1 22b are used to store different types of man- 
agement entities depending on the particular label dis- 
tribution protocol employed. These entities maybe: (a) 
the FEC, for LDP Protocol; (b) the destination node's 
router ID, for non source-routed RSVP; (c) the next 
node's router ID for strict source-routed CR-LDP and 
RSVP; and (d) the next hop in the configured source- 
route for loose source-routed CR-LDP and RSVP. 
These can all be summarized as the next hop that an 
SLSP takes through the network. 50 
[0047] Note that table 122 is hashed based on the IP 
prefix field 122b. There can be several requested 
SLSPs all referring to the same IP prefix at a transit node 
or egress node. Each individual SLSP is identified by a 
separate entry or record 126 in the LSP list 124. How- 55 
ever, there can only be one ingress SLSP associated 
with any given IP prefix on the node 1 0. (In other words, 
an entry 1 26 exists for every next hop request received 




from the LMS 64 as well as one entry for an ingress 
SLSP which has been created on the node. Note too 
that egress SLSPs also request next hop information 
and therefore are included within this table). 
[0048] Each LSP list entry 1 26 comprises the follow- 
ing elements: 

• prev_RwtPtr (126a), next_RwtPtr (1 26f)-Forward 
and backward pointers used to keep track of addi- 
tional entries 126 for a specific IP prefix. All of the 
LSPs associated with the same IP prefix 122b are 
linked together using pointers 126a and 126f. 

• next_EgressPtr (126b), prev_EgressPtr (126c)- 
Forward and backward pointers used to keep track 
of egress SLSPs which may possibly be extended 
when a new LDP Session is configured, as dis- 
cussed in greater detail below. These pointers are 
basically used to implement an LSP egress table or 
list (LET) 130 which is embedded in the RWT 120. 
For example, in Fig. 8 the RWT entries 126 labelled 
"X" and "Y D belong to the LET 130. An entry 126 is 
added to the LET 1 30 whenever a best effort routing 
policy (e.g., LDP Protocol) is employed in setting up 
an SLSP and the node 10 can find no further LDP 
signalling links "closer" to the destination address 
of the corresponding FEC. For example, in estab- 
lishing an SLSP for FEC Z in the reference network, 
node C (which lies at the boundary of the MPLS 
routing domain) cannot find any more LDP signal- 
ling links heading towards the destination address 
of FEC Z, and thus when node C creates a RWT 
entry 126 for this SLSP the entry will be added to 
the LET. 

• fitEntryPtr (126d) - Pointer to the FIT entry 112 
which corresponds to this RWT entry 1 26. The val- 
ue of this field will be null for all entries except for 
ingress SLSPs created at this node. 

• L3_id (126e) - The address or identity of the L3 
processor which initially requested the next hop re- 
quest for the LSP or the address or identity of the 
L3 processor which is used to set up an ingress 
SLSP. 

• lsp_id (126g) - Same as lsp_id 11 2g in FIT 110, ex- 
ceptthat these LSPs may have been initiated at oth- 
er nodes. 

7. Establishing an LDP Session 

[0049] LDP Sessions are configured via management 
requests which are received through the Ul 66 and for- 
warded to MPLS Routing 70. The data obtained by the 
Ul 66 includes the ATM link layer end point of the LDP 
signalling link SI (i:e. - line card address, port, VPI/VCI), 
IP address assigned to the Si, and LDP specific param- 
eters such as label range, label space ID and keep-alive 
timeout 

[0050] MPLS Routing 70 employs a round-robin algo- 
rithm to select one instantiation of the LMS 64 (i.e., one 
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of the L3 processors 54) and requests the associated 
MPLS CAM 65 to establish a new LDP Session. The 
MPLS CAM enables the LDP signalling appGcation on 
the SI selected by the network operator and configures 
the node, including a filtering mechanism (not shown) 
associated with the 12 processor 50, to allow all LDP 
packets associated with a particular LDP signalling SI 
to be propagated (in both the ingress and egress direc- 
tions) between the line cards 12 and the selected LMS/ 
L3 processor 54. Once this is carried out, the LMS 64 
sends out LDP session establishment messages to the 
LDP peer router in accordance with the applicable label 
distribution protocol (e.g., LDP Protocol, CRLDP, 
RSVP). These include "hello" and other session estab- 
lishment messages. 

[0051] Once an LDP Session has been established 
with the LDP peer router, the LMS 64 informs the label 
manager 62 of the negotiated label range for the LDP 
Session (which is a function of establishing an LDP Ses- 
sion as per the draft standards). The LMS 64 also pass- 
es the IP address of the LDP peer router to MPLS Rout- 
ing 70 which stores this address in the router ID field 
104a of the LSLT100. In addition, the LMS 64 passes 
the interface index identifying the LDP signalling SI to 
MPLS Routing 70 which stores it in the iflndexfield 1 08a 
oftheLSLT100. 

8. Establishing an SLSP 

8.1 Procedures at the ingress Node 

[0052] Referring to the reference network, an SLSP 
must be explicitly established at node A for FEC Z by 
the network operator via the NMTI of node A or via the 
N MS which communicates with node A. The instruction 
to configure the SLSP includes as one of its parameters 
Z, i.e., the destination IP address and prefix thereof for 
FEC Z. The command is received and interpreted by the 
Ul 66. 

[0053] The Ul 66 selects a unique LSP ID which, as 
previously discussed, preferably comprises a concate- 
nation of the node's IP router ID and a unique number. 
The Ul 66 then requests MPLS Routing 70 to create an 
SLSP for FEC Z and associate it with the selected LSP 
ID. 

[0054] MPLS Routing 70 requests next hop informa- 
tion for FEC Z from IP Routing 68. This will occur for 
non-source-routed LSPs in order to obtain the next-hop 
information as well as for source-routed LSPs in order 
to verify the information in the source-route (which will 
be supplied by the network operator). More specifically, 
MPLS Routing 70 executes the following procedure to 
initiate the establishment of an SLSP for this new FEC. 
[0055] Referring additionally to Fig. 9, at a first step 
150 MPLS Routing 70 searches the FIT 110 for an ex- 
isting entry 11 2 having the same IP destination address 
and prefix as FEC Z. If such an entry exists in the FIT 
110 then at step 152 MPLS Routing 70 returns with a 



failure code indicating that FEC Z has already been es- 
tablished from this node. At step 158, MPLS Routing 70 
creates a new FIT entry 112 and appends it to the FIT 
110. A corresponding entry 126 is also inserted into the 

5 LSP list 124 for FEC Z in the RWT hash table 122. If 
necessary, MPLS Routing 70 adds a new entry 122 to 
the RWT 120 which includes the IP prefix and address 
of FEC Z, or the IP prefix and address of the first hop in 
the explicit route. 

to [0056] At step 160 MPLS Routing 70 requests IP 
Routing 68 to provide the peer IP address for the next 
hop to reach FEC Z (or the destination node's router id 
for non source-routed RSVP, or the next hop in the con- 
figured source-route for loose source-routed CR-LDP 

15 and RSVP). Once obtained, at step 1 62 MPLS Routing 
70 searches for an LSLT entry 102 which matches the 
next hop router ID. If a matching LSLT entry exists, then 
at step 164 MPLS Routing 70 selects an available LDP 
Session from the corresponding LDP Session list 106. 

20 This is a circular linked list, which is managed such that 
the *ldp_session_list pointer 1 04b in the LSLT entry 1 02 
points to the LDP Session to be used for the next SLSP 
setup which is selected by MPLS Routing 70. Once the 
LDP Session is selected, the recently created FIT entry 

25 112 for FEC Z is linked (viathe **prev_fit Entry and *next- 
RtEntry pointers 112a and 112i) to other Frr entries us- 
ing the same LDP Session. 

[0057] The *next_ldp_session pointer 108d points to 
the next session in the LDP session list. (If there is only 

30 one LDP Session in the list then the *nextJdp_session 
points to itself.) Once the link between the FIT 11 0 and 
LDP session list 106 is created, MPLS Routing 70 up- 
dates the *ldp_session Jist pointer 1 04b to point to the 
next session in the LDP session list with resources. This 

35 results in a round robin approach to selecting LDP Ses- 
sions for a given FEC. If no sessions to the peer LDP 
router have resources, the ldp_session_list pointer 
104b is not updated. In this case, the list is traversed 
once when a path is setup before MPLS Routing 70 

40 stops looking for a session. 

[0058] Note also that if M PLS Rout ing 70 does not find 
an LSLT entry 102 which matches the next hop router 
ID, then no LDP signaling link exists thereto. In this case 
MPLS Routing 70 adds the recently created FIT entry 

45 for FEC Z to the RTL at step 1 66 and returns at step 1 68 
with an appropriate failure code. 

[0059] Once an LDP Session has been selected to 
signal the establishment of the SLSP, then at step 1 70 
MPLS Routing 70 requests the LMS 64 to signal the set 

so up of an SLSP. The LMS 64 of node. A sends a label 
request message, as per the draft LDP standards, to its 
downstream LDP peer router, node B, indicating the de- 
sire to set up an LSP for FEC Z. The label request mes- 
sage is propagated downstream across the MPLS rout- 

55 jng domain in accordance with the routing protocol (hop- 
by-hop or source routed) to the egress node C, and label 
mapping messages are propagated upstream back to 
the ingress node A. Ultimately, as shown in Fig. 10, a 
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label message should be received inbound on the LOP 
signalling link selected by MPLS Routing 70 for FEC Z. 
This label message identifies the label, i.e., VPl/VCI val- 
ue, that should be used to forward IP packets and the 
ATM cells thereof to node B. The label is passed to 
MPLS Routing 70 and to the label manager 62. In addi- 
tion, at step 174 the LMS 64 signals the call processor 
72 to configure an egress interface index for the SI being 
used on the egress line card and port to handle the data 
traffic. (Note that the egress line card will be the same 
line card and port associated with the LDP signaling SI 
for FEC Z.) This "binds" FEC Z to the ATM VPl/VCI label. 
The binding is reported to MPLS Routing 70 which 
searches the FIT 110 at step 176 for the entry 112 
matching FEC Z, whereupon the if Index field 112e is up- 
dated with the egress interface index obtained from the 
call processor 72. 

[0060] I n addition , MPLS Routing 70 updates the fee- 
Status field 112f (Fig. 8B) by setting the retrySeq and 
retrySec counters to zero and sets the ingressSetup flag 
to one thereby indicating successful set up. At step 1 78 
MPLS Routing 70 informs IP Routing 68 about the newly 
established SLSP and its egress interface index where- 
upon the latter task updates its IP forwarding table 75 
(Fig. 6) to add the newly established egress interface 
index (shown schematically by ref . no. 76) to the appro- 
priate list 75c. IP Routing 68, in turn, may have a number 
of potential egress interface indexes in list 75c, which 
may be used to forward a packet. In order to decide 
amongst these alternatives, IP Routing 68 employs a 
priority scheme which grants an MPLS-enabled egress 
interface index (there can only be one per FEC) higher 
priority than non-MPLS egress interfaces. The priority 
scheme is carried out through the mechanism of a bit 
map 75d (only one shown) which is associated with 
each entry of the egress interface index list 75c. The bit 
map 75c indicates what type of application, e.g., SLSP 
or IP, is associated with the egress interface index entry. 
Following this priority scheme, at step 180 IP Routing 
downloads the newly created egress interface index 76 
to the forwarding tables 30 of each IP forwarding mod- 
ule. (Table 30 only lists a single egress interface index 
for each IP address or prefix thereof). Asynchronously, 
M PLS Routing 70 also informs the Ul 66 at step 1 82 that 
the ingress SLSP for EEC Z has been successfully cre- 
ated. 

[0061] In the event that no label mapping message is 
received within a predetermined time period, or the sig- 
nalling message that is received from node B denies the 
setup of an SLSP for FEC Z, the LMS 64 informs MPLS 
Routing 70 of the failure at step 1 84. MPLS Routing con- 
sequently places the'Flt entry 11 2 for FEC Z on the RTL 
116rsets the fecStatus ingressSetupfield (Fig. 8B) to 
zero and increments the value of the retrySeq field (up 
to a max of 6). At step 186, MPLS Routing informs the 
Ul 66 of the failure. 

[0062] The retry, mechanism for FIT entries is a linear 
back off mechanism which causes an SLSP path setup 



to be retried at 1 0, 20, 30, 40, 50, and 60 seconds. There 
is one retry timer associated with MPLS Routing 70 
which goes off every 10 seconds. At this point MPLS 
Routing traverses the RTL 116. decrementing the 

5 amount of time (retrySec - Fig.8B) left for each FIT entry 
112 in the RTL 116. If the retrySec value is zero, the FFT 
entry 112 is removed from the RTL 116, the retry se- 
quence number is incremented by one and another at- 
tempt is made to establish the ingress SLSP. If the retry 

10 is successful retrySeq is set to zero and the ingressSet- 
up flag is set to 1 . If the retry is unsuccessful then the 
FIT entry is added back to the RTL, retrySeq is incre- 
mented (max. sequence number is preferably 6). When 
the retrySeq counter is increased, the time period within 

15 which MPLS Routing 70 will retry to set up the SLSP 
also increases to the next highest interval. For instance, 
when retrySeq increases from 2 to 3 the time interval 
between retries increases from 20 to 30 seconds, I.e. 
retrySec is set to 30. When retrySeq is equal to 6, retries 

20 are 60 seconds apart 

8.2 Procedures at Transit Nodes 

[0063] At transit node B, a label request message for 

25 FEC Z is received on MPLS signaling link 84 and for- 
warded by the L2 processor 50 to the responsible LMS 
64. The LMS 64 requests next hop information from 
MPLS Routing 70 which, in turn, retrieves the next hop 
router ID for FEC Zfrom IP Routing 68, stores the next 

30 hop router ID in the RWT 120, selects a downstream 
LDP Session to the next hop LDP peer router, node C, 
and supplies this data to the LMS 64, as discussed pre- 
viously. The LMS 64 then requests the label manager 
62 to reserve a VPIA/CI label from within the negotiated 

35 label range (determined when the LDP Session with the 
upstream node A was established). This label is for- 
warded upstream to node A when the label mapping 
message is sent thereto Then, if necessary, the LMS 64 
which received the upstream label request message will 

40 signal another instantiation of the LMS (on a different 
L3 processor 54) responsible for the downstream LDP 
Session in order to progress the Label Request mes- 
sage to node C. 

[0064] When a label mapping message is received 
45 from the downstream signalling link, the LMS 64 signals 
the call processor 72 to establish a cross-connect be- 
tween the label, i.e., VPIA/CI, associated with upstream 
node A and the label, i.e., VPl/VCI, associated with the 
downstream node C to thereby establish downstream 
so data flow. On the transit node this results in an ATM style 
cross-connect, as discussed above. In addition, the 
LMS 64 responsible for the upstream LDP Session to 
node A forwards a label mapping message to it with the 
label previously reserved by the label manager 62. 
55 [0065] Note that for source-routed SLSPs it may not 
be necessary for the transit node B to obtain next hop 
information from IP Routing 70. This is, however, a pre- 
ferred feature which enables the transit node to confirm 
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thr ough its internaJ routing tables that the next hop pro- 
vided in the source route list is accurate (e.g., by check- 
ing whether the next hop is listed under the requested 
IP destination address or prefix). If the explicitly routed 
next hop cannot be confirmed, then an error can be de- 5 
dared. 

8.3 Procedures on Egress Node 

[0066] On the egress node C, a label request mes- 10 
sage is received on the upstream signalling link with 
node B and forwarded by the L2 processor 50 to the 
responsible LMS 64. The LMS 64 requests next hop in- 
formation from MPLS Routing 70 which, in turn, re- 
quests next hop information from IP Routing 68. In this is 
case, however, one of the following circumstances aris- 
es: (1) the next hop router ID returned by IP Routing 68 
is the current node; or (2) the next hop Is found, but no 
LDP Session exists to the next hop (i.e., the edge of the 
MPLS domain is reached). In either of these cases, 20 
M PLS Routing 70 informs the LMS 64 that the SLSP for 
FEC Z must egress at this node, whereby the LMS 64 
sends a label mapping message to the upstream node 
B as previously described but does not (and cannot) 
progress the label request message for FEC Z forward. 25 
In this case, MPLS Routing 70 adds an entry 126 in the 
RWT 120, as previously discussed, but also adds the 
newly created RWT entry 1 26 to the LET 130. 
[0067] In this case, the LMS 64 instructs the call proc- 
essor 72 to establish an SI configured for IP forwarding. 30 
This SI has an ATM endpoint (i.e., VPI/VCI) equal to the 
VPI/VCI used as the MPLS label between nodes B and 
C for the SLSP. 

9. Switching/Routing Activity 35 

[0068] Having described the set up of an SLSP for 
FEC Z, the manner in which IP packets associated with 
FEC Z are processed is now briefly described. At the 
ingress node A the IP packets arrive at port 1 4A1 in the 40 
form of plural ATM cells which the IP forwarder 22A re- 
assembles into constituent IP packets. Once the desti- 
nation IP address of the received packet is known, the 
IP forwarder 22A examines its forwarding table 30 for 
the "closest" entry. This will be the entry for FEC Z that «s 
was downloaded by IP Routing 68 In connection with 
the establishment of the SLSP for FEC Z. Thus, the for- 
warding table 30 provides the egress interface index 76, 
comprising the identity or address of the egress line card 
12B; egress port 14B1 and egress SI number The so 
egress interface index is attached to the packet. The in- 
gress IP forwarder 22A also selects a Tl 1 8 to transport 
the packet over the switching fabric 20 to the egress IP 
forwarder 22B, based in part on the COS field encapsu- 
lated in the packet. The packet is then re-segment for 55 
transport across the switching fabric 20 on the selected 
Tl 1 8 and received by the egress IP forwarder 22B. The 
egress IP forwarder 22B, in turn, extracts the egress SI 




and COS information attached to the packet and modi- 
fies it to match the encapsulation indicated by the egress 
interface index (i.e., egress SI). This includes attaching 
the VPI/VCI label to the packet. The packet is subse- 
quently segmented into constituent ATM cells and trans- 
mitted out of the egress port 1 4B1 with the VPI/VCI val- 
ues indicated by the egress SI. 

[0069] On the transit node B, the ATM ceils corre- 
sponding to the IP packets are received by an ingress 
port. The CAM 15 returns an ATM egress connection 
index, whereby the cells are processed as ATM cells. 
The ingress line card 12A also attaches internal ad- 
dressing information retrieved from the CAM 15A to 
each cell, thereby enabling the cells to be routed to the 
egress line card which replaces the VPI/VCI value of the 
cells. The egress line card then transmits the cell using 
the new VPI/VCI value. Note that In this case the IP for- 
warding modules 22 were not involved in the switching 
activity and there was no need to re-assemble and re- 
segment the IP packet, or perform the IP routing lookup. 
[0070] On the egress node C, the ATM cells corre- 
sponding to the IP packets are received by an ingress 
port and processed in accordance with the SI configured 
for the VPI/VCI carried by the cells. This SI is configured 
such that the cells are sent to the IP forwarding module 
22Afor re-assembly into the higher-layer IP packets and 
thereafter processed as regular IP packets. 

10. Network Topology Changes 

10.1 New LDP Session 

[0071] When a new LDP Session is established on 
node 10, the LMS 64 signals MPLS Routing 70 about 
this event and informs it about the interface index for the 
new LDP Session. The signal arises whether the node 
is the initiator of the new LDP Session orthe respondent. 
Referring additionally to the flow chart of Fig. 1 1 , at step 
190 MPLS Routing searches for the peer router ID IP 
address in the LSLT 1 00. If an LSLT entry 1 94 for this 
router is found, then at step 192 MPLS Routing 70 ex- 
amines the corresponding LDP Session list 106 to en- 
sure that no entries 1 08 exist for an LDP Session having 
the same interface index as the new LDP session! If no 
such entry is found, a new entry 108 is created at step 
1 95. If such an entry is found, an error is returned. If no 
LSLT entry 104 is found which matches the peer router 
ID for the newly configured LDP Session, then at step 
1 94 M PLS Routing creates and inserts a new LSLT entry 
104, following which the LDP session list entry 106 is 
created at step 195. 

[0072] At step 196, MPLS Routing 70 traverses the 
LET 1 30. For each RWT entry 1 26 belon ging to the LET, 
the corresponding FEC is determined from hash table 
122, and at step 200 the next hop router ID for that FEC 
is requested from IP Routing 68. At step 201 the next 
hop router ID is compared against the peer router ID.of 
the newly configured LDP Session. If no match is found, 
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control returns to step 1 98, and if a match is found, con- 
trol passes to step 202. At step 202, MPLS Routing 70 
instructs the LMS 64 to send a label request message 
to the newly reachable peer routerforthe identified FEC. 

1 0.2 Signaling Link Failure 

[0073] When an LDP Session fails on a node it stops 
forwarding all SLSPs using the associated VPI/VCI 
range (stored in the label manager 62) and removes the 
cross-connects from the node. The node also sends a 
label withdraw message to the upstream peer for each 
SLSP associated with the failed LDP Session. For in- 
stance, if the MPLS link 84BC (Rg. 7) fails, node B 
sends a label withdraw regarding FEC Z to the ingress 
node A. When the label withdraw message is received 
at the Ingress node A, it stops using the path (IP hop- 
by-hop forwarding is used instead) and immediately re- 
initiates the steps described previously to re-establish a 
path for FEC Z. If this does not succeed, then the SLSP 
for FEC Z is placed on the RTL 11 6 following which the 
retry procedures as previously described are effected. 
[0074] Furthermore, when an LDP Session becomes 
inoperative in the ingress node A for whatever reason, 
the LMS 64 informs MPLS Routing 70. As part of this 
call, the LMS 64 provides MPLS Routing 70 with the 
peer router ID IP address. MPLS Routing 70 then 
searches for the peer IP address in the router ID field 
1 04a of the LSLT 1 00. If there is no entry for the peer IP 
address, an error is returned. If there is an entry 104a 
for the peer IP address, the corresponding session list 
1 06 is searched for the failed LDP Session. If there is a 
matching LDP Session entry 108, it is removed from the 
session list 106. 

[0075] The f it Jist_entry pointer 1 08b of the removed 
session list entry 1 06 points to the list of all FIT entries 
112 representing all ingress SLSPs using the failed LDP 
Session. For each of these entries, MPLS Routing 70 
immediately tries to re-establish the ingress SLSP as 
described above to see if there is an alternate LDP Ses- 
sion that may be used to set up the ingress SLSP. If the 
retry is unsuccessful, the ingress SLSP goes on the RTL 
116 andthe retry procedures outline above are followed. 

1 0.3 IP Routing Changes 

[0076] Overthe course of time, IP Routing 68 may dis- 
cover a new next hop for FEC Z. For example, in the 
reference network IP Routing on node B may discover 
that the next hop for FEC Z should be node D (not 
shown). Upon such a discovery, IP Routing 68 on node 
B informs MPLS Routing 70 of the new next hop router 
ID for FEC Z MPLS Routing 70 uses the following proc- 
ess to re-route the SLSP for FEC Z: First, it searches 
for a RWT entry 122 matching the IP prefix address, e. 
g., FEC Z, which has changed in the IP Routing table 
75. In the event no entry 122 is found MPLS Routing 
returns otherwise it continues and next searches for an 



LSLT entry 104 that matches the router ID of the new 
next hop D. If there is an LSLT entry 1 04 and hence LDP 
Session to the new router D t MPLS Routing requests 
the LMS 64 to progress each transit SLSP in the RWT 

5 list 1 24 pointed to by the matching RWT entry 1 22 using 
the LDP Session to router D. Thus transit SLSPs are re- 
routed to the new next hop router D. However, if there 
is no LSLT entry 102 for the router ID of the new next 
hop and hence no LDP Session therefor, then MPLS 

10 Routing 70 places each transit SLSP in the RWT list 1 24 
corresponding to the old-hop router on the LET 1 30 and 
informs the LMS 64 that it should consider such SLSPs 
as egress SLPs. The LMS 64, in turn, instructs the call 
processor 72 to set up egress Sis for the egress SLSPs. 

15 [0077] M PLS Routing 70 also searches for a FIT entry 
112 which matches the affected FEC. If there is a FIT 
entry 112 that matches the FEC and the ingress_setup 
flag of the fee-status field 112f is non zero (i.e., the path 
is set up), MPLS Routing 70 requests that the LMS 64 

20 close the ingress SLSP by sending a label release mes- 
sage to the downstream routers. MPLS Routing 70 then 
search es for an LSLT entry 1 04a that matches the router 
ID IP address for the new next hop. If there is such an 
LSLT entry, then an LDP Session is selected from the 

25 corresponding LDP session list 106, andthe procedures 
for establishing an ingress SLSP are followed as de- 
scribed above. 



30 



1 0.4 Physical Link Failure 



[0078] When a physical link between two nodes fail, 
then signaling links 82 and 84 (see Fig. 7) for both M PLS 
signaling and IP routingfail. In the present embodiment, 
IP Routing 68 realizes that the link is down and updates 

35 its routing table 75 before the LMS 64 realizes that any 
LDP Sessions thereover are down. This is accom- 
plished by suitably setting "time out" periods for LDP 
Sessions and signaling sessions in IP Routing such that 
interface failures are reflected much quicker into IP 

40 Routing 68 than MPLS Routing 70. Accordingly, IP 
Routing 68 informs MPLS Routing 70 about a new next 
hop router ID for affected SLSPs and as previously de- 
scribed MPLS Routing 70 will reroute these SLSP paths 
from the current node, using the new next hop router 

45 identified by IP Routing 68. This is more efficient than 
tearing down the affected SLSPs back to the ingress 
node and resignaling them as would have occurred if 
MPLS Routing 70 realizes the signaling link is down. 
[0079] The foregoing embodiment has been de- 

50 scribed with a certain degree of particularity for the pur- 
poses of description. Those skilled in the art will under- 
stand that numerous variations and modifications may 
be made to the embodiments disclosed- herein-without 
departing from the spirit and scope of the invention. 

55 
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Claims 

1. A method of operating a communications network 
having a plurality of interconnected nodes, the 
method comprising: 5 

establishing a connection path from an ingress 
node to an egress node through a plurality of 
intermediate nodes; 

associating said connection path with a net- 10 
work-wide unique identification; 
on said ingress node, storing said path identifi- 
cation so as to indicate that said path originates 
at said ingress node; 

on each said intermediate node, storing said 1 $ 
path identification so as to indicate that said 
path transits said intermediate node; and 
on said egress node, storing said path identifi- 
cation so as to indicate that said path termi- 
nates at said ingress node. 20 

2. The method according to claim 1 , wherein the step 
of establishing a connection path includes signal- 
ling a connection set-up request from said ingress 
node through said intermediate nodes to said 25 
egress node. 

3. The method according to claim 2, wherein the step 
of establishing a connection path further includes 
signalling an acknowledgement from said egress 30 
node through said intermediate nodes to said in- 
gress node in response to said connection set-up 
request. 

4. A method of transmitting packets received from a 35 
connectionless network wherein each packet in- 
cludes a destination network address, the method 
including: 

providing a forwarding table wherein each net- *o 
work address is associated with a single inter- 
face index which dictates an output port and a 
connection over which corresponding packets 
should transported; 

forwarding a connectionless packet to an out- 
put port based on an interface Index obtained 
from the forwarding table and transmitting the 
connectionless packet over the corresponding 
connection; 

maintaining a routing table for routing connec- so 
tionless packets over a connection -oriented 
network, said routing table associating each 
network address with one or more interface in- 
dexes; 

associating each interface index with an appii- 55 
cation, one application being connectionless 
routing and one application being label switch- 
ing; and 
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downloading interface indexes from said rout- 
ing table to corresponding entries in said for- 
warding table such that the label switching ap- 
plication has a higher priority than the connec- 
tionless routing appDcation. 

5. A method of transmitting packets, including: 

receiving (a) connection-oriented packets hav- 
ing a label associated therewith, said label be- 
ing a connection identifier, and (b) connection- 
less packets carrying a network address and 
having no label associated therewith; 
providing a forwarding table wherein each net- 
work address is associated with a single inter- 
face index which dictates an output port and a 
connection over which corresponding connec- 
tionless packets should transported; 
providing a switching table for switching ingress 
labels into egress labels; 
forwarding a connectionless packet to an out- 
put port based on an interface index obtained 
from the forwarding table; 
forwarding a connection-oriented packet to an 
output port based on said switching table; 
transmitting connection -oriented and connec- 
tionless packets over the corresponding con- 
nections; 

maintaining a routing table for routing connec- 
tionless packets over a connection-oriented 
network, said routing table associating each 
network address with one or more interface in- 
dexes; 

associating each interface index with an appli- 
cation, one application being connectionless 
routing and one application being label switch- 
ing; and 

downloading interface indexes from said rout- 
ing table to corresponding entries in said for- 
warding table such that the label switching ap- 
plication has a higher priority than the connec- 
tionless routing application. 

6. A network node, comprising: 

a plurality of input and output ports operative to 
receive and transmit packets carrying a con- 
nection identifier for transport over a connec- 
tion-oriented network; 

switching logic for switching said connection- 
oriented packets from one of said input ports to 
one of said output ports based on one of said 
connection identifiers; 

segmentation and re-assembly logic for ena- 
bling said ports to assemble connectionless 
packets from the payloads of one or more con- 
nection-oriented packets on ingress and to seg- 
ment each such connectionless packet into one 
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or more connection-oriented packets on 
egress, each said message packet carrying a 
network address for transport over a connec- 
tionless network; 

forwarding iogic for forwarding connectionless 5 
packets from one of said input ports to one of 
said output ports, said forwarding logic includ- 
ing a forwarding table which associates a net- 
work address or a group of network addresses 
with a single interface index, said interface in- io 
dex indicating the identity of one of said output 
ports and enabling a connection identifier to be 
specified for segmentation of the connection- 
less packet at the indicated output port; 
routing iogic for forwarding a connectionless 15 
packet to a next-hop based on the network ad- 
dress carried by the packet, said logic including 
a routing table which associates a network ad- 
dress or group thereof with at least one inter- 
face index, said logic being enabled to down- 20 
load an interface index for a given network ad- 
dress or group thereof from said routing table 
to the same network address entry in said for- 
. warding table time; and 

logic for setting up a label switched path where- 25 
in a connectionless packet is associated with a 
connection identifier which functions as a label 
so that transit nodes in the label switched path 
can switch the connection-orientated packets 
constituting connectionless packets based on 30 
the connection identifier without re-assembling 
the connectionless packets, said logic associ- 
ating the label switched path with an interface 
index; 

35 

wherein said interface indexes are associated 
with a priority hierarchy in which interface indexes 
associated with label switched paths have a higher 
priority than interface indexes associated with con- 
nectionless routing, and wherein said routing logic 40 
does not overwrite a forwarding table entry having 
an interface index associated with a label switched 
path with an interface index associated with con- 
nectionless routing. 
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Figure 4 





Description 


Default 


NMT1 


SNMP 


NCI 


CXI 


ID number 


A identification number assigned for 
this SI^ unique within a subsloL This 
value is internally assigned and cannot 
be changed. This is 5 digit number 
field. 


None 


R 




- 


- 


Hndpoint 


The ATM endpoint (shelf-slot-wfcsloi- 


None 


R/W 








Name 


Name of the SI. This is 16 character 
lead, string field 


Empty 


R/W 


- 


- 


- 


Application 


Application's) provided by this SL This 
is a boolean vector (i.e. bit map) 
indicating whether each of forwarding, 
routing and LDP is enabled. 


Forward 


R/W 








Address type 


Type of the IP address field. Valid type 
supported are unnumbered and IPv4. 


Un- 
numbered 


RAV 


m 






TP address 


The IP address" of the service interface. 
Represented to the user in standard 
*Mr*ftpr! decimal*" format "Illegal 7 * IP 
addresses (e.g. O.O.O.O, 
255.255.255.255) are blocked 


Un- 
. assigned 


R/W 




- 

* 


- 


jLr smurcss 
prefix length 


Number of bits in the IP address which 
constitute the (subnetwork H>. A 
number in the range of 0..32. 


None 


R/W 








Neighbour 
address type 


Type of the neighbour IP address field. 
Valid typs supported are unnumbered 

and IPv4. 


Un- 

ntunbercd 


R/W 








Neighbour IP 
address 


The IP address used at the termination 
of the SI at the neighbouring router. 
Represented to the user in standard 
"dotted decimar format "MegariP 
addresses (eg 0.0.0.0, 
25*5.255.255.25 5> are blocked. 


Un- 
assigned 


R/W 


- 


- 


- 


Encapsulation 


ii neppsu * anon usco on uie oi. 
(RFC1483LLC/SNAP routed IP, 
KFC1483 NULL) 


NULL 


R/W 








MTU 


Maximum Transmission Unit. 


2016 
octets 


R 








Ingress traffic 
contracts 


An ingress Uafliu ronliaclsUucture 
consists of an action (disable, tag, 
discard), a committed information rate 
On b/s) arid a burst size (in bytes). 
Eight ingress traffic contract structures 
are contained in each SI; each applies to 
aCoS. 


disable 

cm o 

BS0 


R/W 








Status 


Status of Uie service interface. (Up, 
Down). 


Down 


R 









Service Interface Parameters 



BNSDOCtD: <EP^ 12l5857A2J_5 



18 




19 

BNSDOC1D:<EP 121 5857 A2_l_> 




BNSOOClt): <EP 1215857A2_I_> 



20 




BNSDOCID: <EP 121 5857 A2_l_> 



21 




EP 1 215 857 A2 



line card address 
port 

sLnumber 
L3id~ 



s 



108a 



Figure 8A 



t.ti 

ingress_setup 
retrySeq 
retrySec 



Figure 8B 



^112f 



BNSDOCIO. <EP 1 21 5857A2_I_> 



22 



EP 1 215 857 A2 



<^StablishSLSP^> 

Search FIT 
forFECZ 




-150 




N 



Create and insert 
FIT & RWT entries 



158 



request next hop peer 
router IP address from 
IP routing 




-160 



162 



166 





Place FIT 


X 




entry on RTL 







Y 


> 


f 


Select LDP 


session, update 


LSLX and FIT 


> 


f 



164 



C^7~CallLMS 



170 




Figure 9 



23 




EP 1 215 857 A2 




on Setup 
failure or 
timeout 



184" 



Place FIT 
entry for 
FECZonRTL 



186' 



Inform 
Ul 



LMS 



170 



on Label 
Mapping 



Bind FECZ 
to label 



Update FIT 
entry for 
FECZ to 



.174 



.176 



Inform IP Routing 
about new egress 
Interface index 



.178 



Download 
to forwarding 
table 30 



.180 



Inform Ul, 
Label Manager 



.182 



Figure 10 



BNSDQCID: <EP 121 5857 A2 I > . 



24 



EP 1 215 857 A2 





3- 



Create LSLT 
entry 104 



Create LDP session 
' list entry 106 • 



.194 



Create LDP session 
list entry 108 



.196 



Traverse LET 



.198 



Request next hop 
router ID for FEC 
of SLSP in LET 



-200 




202 



Send new next 
hop message 
toLMS 



Figure 11 



25 



(19) 



J 



Europaische^ Rntamt 
European Patent Office 
Office europeen des brevets 



(11) 



ml 

EP1 215 857 A3 



(12) 



(88) Date of publication A3: 

11.06.2003 Bulletin 2003/24 

(43) Date of publication A2: 

19.06.2002 Bulletin 2002/25 

(21) Application number. 01403161.1 

(22) Date of filing: 07.12.2001 



EUROPEAN PATENT APPLICATION 

(51) mtci7: H04L 12/56, H04L 12/46 



(84) 


Designated Contracting States: 


• Behki.Nutan 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Nepean, Ontario K2G 0M7 (CA) 




MC NLPTSETR 


• Toscano, David 




Designated Extension States: 


Nepean, Ontario K2J 4N9 (CA) 




AL LT LV MK RO SI 


• Dubuc, Ken 






Ottawa, Ontario K2B 8K3 (CA) 


(30) 


Priority: 08.12.2000 CA 2327918 


(74) Representative: Lenne, Laurence et al 


(71) 


Applicant: Alcatel Canada Inc. 


Cabinet Feray Lenne Conseil 


Kanata, Ontario K2K 2E6 (CA) 


44/52, rue de la Justice 




75020 Paris (FR) 


(72) 


Inventors: 




• 


Reeves, Mike 






Kanata, Ontario K1S 3Y6 (CA) 





(54) System and method for operating a communication network on an ATM platform 



(57) A system and method of operating a communi- 
cations network having a plurality of interconnected 
nodes is provided by: establishing a connection path 
from an ingress node to an egress node through inter- 
mediate nodes; associating the connection path with a 
network-wide unique identification; on the ingress node, 
storing the path identification so as to indicate that the 



path originates at the ingress node; on each intermedi- 
ate node, storing the path identification so as to indicate 
that the path transits the intermediate node; and on the 
egress node, storing the path identification so as to in- 
dicate that the path terminates at the ingress node. 



CO 
< 

m 
oo 

io 

CL 
LU 



Printed by Jouve, 75001 PARIS (FR) 



. BNSOOClD:.<EP 1215657A3J_> 



EP 1 215 857 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 81 48 3161 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where 
ol relevant passages 



DAVID B. JOHNSON: °The Dynamic Source 
Routing Protocol for Mobile Ad Hoc 
Networks 0 [Online] 

17 November 2000 (2900-11-17) , IETF 
XP002231891 

Retrieved from the Internet: <URL: 

http : //www. i etf.org/proceedi ngs/88dec/ I -D/ 

draft-ietf-manet-dsr-04.txt> 

[retrieved on 2003-02-19] 

* page 1, line 17 - line 26 * 

* page 1, line 35 - line 38 * 

* page 5, line 3 - page 6, line 33 * 

LE FAUCHEUR F: "IETF Multiprotocol Label 

Switching (MPLS) Architecture 8 

IEEE INTERNATIONAL CONFERENCE ON ATM, XX, 

XX, 

22 June 1998 (1998-06-22), pages 6-15, 
XP0O21 15225 

* page 9, left-hand colunn, line 51 - 
right-hand colurm, line 13 * 

* page 12, left-hand column, line 25 - 
line 47 * 

* page 13, left-hand column, line 51 - 
right-hand column, line 6 * 

GORAN HAGARD - MIKAEL WOLF: 
"Multiprotocol label switching in ATM 
networks" [Online] 

1998 , ERICSSON REVIEW NO* 1 XP082231892 
Retrieved from the Internet: <URL: 
http : //www. eri csson . com/about/publ i cati ons 
/revi ew/1998 01/f i 1 es/1998015 . pdf> 
[retrieved on 2003-02-19] 

* page 35, right-hand column, line 32 - 
page 36, right-hand column, line 11 * 

-/-- 



The present search report has been drawn up for all claims 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION pm.CI.7) 



1-3 



H04L12/56 
H04L12/46 



1-3 



TECHNICAL FIELDS 
SEARCHED (Irt.CLT) 



H04L 



1-3 



i 

CM 

-8 

i 

2 



Place of search 

MUNI CH 



Dale of completion erf the search 

9 April. 2803 



Jimenez Hernandez, P 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant ff taken alone 

Y : particularly relevant 8 combined wtti another 

document of the same category 
. A : technological background 
O : non-written disclosure 
P : intermediale document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on. or 

alter uie fifing dale 
D : document cried in the appBcation 
L : document cited for other reasons 



& : member ol the same patent family, corresponding 
document 



BNSDOCID: <EP 1215B57A3_l_>.. 



2 



> 



EP 1 215 857 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application number 

EP 01 40 3161 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with Indication, where appropriate, 
of relevant passages 



* Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (taLCL7) 



X,D 



ROSEN E C ET AL: "Multiprotocol Label 1-3 
Switching Architecture" 
IETF, 

August 1999 (1999-08), XP002195041 

* page 24, line 21 - line 39 * 

* page 34, line 14 - page 35, line 13 * 

* page 38, line 3 - line 17 * 

LOA ANDERSSON : "LDP Specification" 1-3 
[Online] 

August 20G0 (2000-08) , IETF XP002231893 
Retrieved from the Internet: <URL: 
http: //www. i etf . org/proceedi ngs/00dec/I -D/ 
draft- i etf -mpl s-ldp-11 . txt> 
[retrieved oh 2003-02-18] ! 

* the whole document * 

BRUCE DAVIE: "MPLS using LDP and ATM VC 1-3 
Switching" [Online] 

June 2000 (2000-06) , IETF XP002231894 
Retrieved from the Internet: <URL: 
http://www.ietf.org/proceedings/O0dec/I-D/ 
draf t-i etf -mpl s-atm-04 . txt> 
[retrieved on 2003-02-18] 

* the whole document * 



VEERARAGHAVAN M ET AL: "INTERNETWORKING 
OONNECTTONtESS AND CONNECTION-ORIENTED 
NETWORKS 0 

IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE 

CENTER. PISCATAWAY, N.J, US, 

vol. 37, no. 12, December 1999 (1999-12), 

pages 130-138, XP00O908335 

ISSN: 0163-68G4 

* the whole document * 

-/-- 



The present search report has been drawn up for ail claims 



TECHNICAL FIELDS 
SEARCHED (lrrt.CI.7) 



4-6 



8 
I 



I 

£ 
2 



Ptaee o* search 

MUNICH 



Dale of completion ol the search 

9 April 2003 



Jimenez Hernandez, P 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant H combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document but published on. or 

after the fifing date " " " 
D : document cited in the appScation 
L : document cited for other reasons 

& : member of the same patent family, corresponding 
document 



BNSDOCID: <EP_^1215857A3J_> 



3 



'0 



EP1 215 857 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 01 49 3161 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
ot relevant passages 



ORLAMUENDER H: "IP UND ATM" 
FERNMELDE-INGENIEUR, BAD W1NSHEIM, DE, 
vol. 53, no. 4, April 1999 (1999-04), 
pages 1-35, XP000998777 
ISSN: 0015-OlOX 

* page 22, line 25 - page 27, line 8 * 

EP 0 884 923 A (HITACHI LTD) 
16 December 1998 (1998-12-16) 

* the whole document * 

PATENT ABSTRACTS OF JAPAN 
vol. 1998, no. 12, 
31 October 1998 (1998-10-31) 
& JP 10 200533 A (NEC CORP) , 
31 July 1998 (1998-07-31) 

* the whole document * 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPUCAHOH flntCU) 



4-6 



4-6 



4-6 



The present search report has been drawn up tor all claims 



TECHNICAL FIELDS 
SEARCHED (tnLCt.7) 



Race o1 

MUNICH 



Date of completion of the search 

9 April 2003 



Examiner 

Jimenez Hernandez, P 



<=>. 

_8 



CATEGORY OP CITED DOCUMENTS 

X : partkaj&rty relevant if taken atone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earfier patent document, but pubBshed on. or 

alter the filing date — - 

D : document died In me application 
L : document cited for other reasons 

&7rnernber ot Sielame paten"namBy, conpsponding 



BNSDOCID: <EP 121 5857 A3J_> 



4 



EP1 215 857 A3 




European Patent 
Office 



EP 01 49 3161 



Application Number 



CLAIMS INCURRING FEES 



The present European patent application comprised at the time of filing more than ten claims. 

□ Only part of the claims have been paid within the prescribed time fimit The present European search 
report has been drawn up for the first ten claims and for those claims for which claims fees have 
been paid, namely dairrtfs): 



□ No claims fees have been paid within the prescribed time limit. The present European search report has 
been drawn up for the first ten claims. 



LACK OF UNITY OF INVENTION 



The Search Division considers that the present European patent application does not comply with the 
requirements of unity of invention and relates to several inventions or groups of inventions, namely: 



see sheet B 



Ijn All further search fees have been paid within the fixed time limit. The present European search report has 
I — I been drawn up for ail claims. 

□ As all searchable claims could be searched without effort justifying an additional "fee, the Search Division 
did not invite payment of any additional fee. 

□ Only part of the further search fees have been paid within the fixed time limit. The present European 
search report has been drawn up for those parts of the European patent application which relate to the 
inventions in respect of which search fees have been paid, namely claims: 



□ None of the further search fees have been paid within the fixed time limit. The present European search 
report has been drawn up for those parts of the European patent application which relate to the invention 
first mentioned in the claims, namely claims: 



BNSDOCID: <EP 1215857A3_I_> 



5 




EP 1 21 5 857 A3 



4 



European Patent 
Office 



LACK OF UNITY OF INVENTION 
SHEET B 



EP 81 46 3161 



Application Kurofcer 



The Search Division considers lhat the present European patent application does not comply with the 
requirements of unity of invention and relates to several inventions or groups of inventions, namely: 

1. Claims: 1-3 

Method of operating a cormnini cations network based on 
establishing a path and associating said path with a 
network -wide unique identification 



2. Claims: 4-6 

Method and corresponding apparatus for transmitting packets 
from a connectionless network over a connection-oriented 
network. 



BNSOOCJD. <EP . 1215BS7A3 I >. 



6 



EP 1 215 857 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 01 40 3161 



This annex Gsts the paten! family members relating to the paten! documents cited in the above-mentioned European search report 
The members are as contained In the European Patent Office EDP file on 

The European Patent Office is In no way liable for these particulars which are merely given lor the purpose of information. 

09-04-2963 



Patent document 
cited in search report 



Publication 



Patent family 
member(s) 



Publication 
date 



EP 9884923 



16-12-1998 



JP 
EP 
US 
US 



10341236 A 
0884923 A2 
6108304 A 
6512745 Bl 



JP 10200533 



31-07-1998 JP 
US 



2842530 B2 
6169739 Bl 



22-12-1998 
16-12-1998 
22-08-2000 
28-01-2003 



06-01-1999 
82-01-2001 



i For more details about this annex : see Official Journal of the European Patent Office, No. 1 2/82 



BNSDOCICh <EP_^121S8S7A3_L> 



7 



